给着急的朋友先说结论：

目前唯一的办法，就是硬扛。

但不是所有直接堆机器，直接堆带宽就叫做硬扛。

硬扛有两个必选项，任一不满足，硬扛必然失败，或者大打折扣。

一、这个大家多说了千万遍，就是：带宽。

这是一切的前提。带宽不够，必然失败。

小IDC会自保，有爆出直接拔目标机器网线的。如果你的带宽不够，连攻击流量都容纳不下，那正常流量又怎么办呢？还是已经来不及管了？

所以先要有足够容纳攻击流量的带宽。

所以，大IDC是首选。

然后，这个第一点，有个提升的空间：分布式带宽。也就是多个机房，需要业务采用分布式架构配合。只要你业务拆分和分布式架构做的到位，一个机房带宽不够，其他机房来凑！

只要所有机房的总带宽，能吞噬攻击流量即可。

所以这对IDC的选择提出了一个条件：要有多机房，异地多机房也行（这会更考验业务的的拆分和分布式的架构能力）。然后，这背后意味着一个必要条件：DNS的更新速度，或者负载均衡服务的灵活性。

之后，还有一个隐藏的更深的Plus要求：IDC各个机房之间，是否有专线之直连，以及业务各个机房之间的通讯，能否走专线？

如果没有，机房间通讯靠公网，那机房的带宽必须能吞噬全部的攻击流量，否则在攻击到该机房时，该机房仅能当作一个蜜罐系统使用……（既然大家都搞安全，蜜罐我就不用再解释了）

所以，总结一下第一点：

带宽大于攻击流量；或者多机房总带宽大于攻击流量，且1：机房不会给你拔网线，且2：机房之间有专线链接，且3：业务各机房间的通讯可以走专线。

二、高度灵活的分布式架构。

这个说第一点后半部分的时候，已经点明了。

注意：不是分布式，而是：高度灵活的分布式。

这会产生以下要求：

1.  你的业务需要有分布式提供服务的能力。也就是说，在多个机房，同时提供服务。业务的客户可以随机，或者随意选择，或则被分配至任意机房。当用户在A机房下线/断线后，用户马上在B机房登陆，业务需要有能持续连贯服务的能力，而不能说，数据还没同步过来。

2.  这可能意味着，如果业务的数据不能很好的同步转移，那机房后面还会有内部共享的后端内部机房。换句话说，分布式技术不过硬，那就用钱（多个机房和专线）来砸。

3.  如果业务的分布式能力还行。那对长链接来说，业务的gate，只能做用户身份的代理，而不能再处理其他任何的稍微重量点的业务。这样才能确保一旦断线，用户再异地登陆的快速转移。否则业务在用户转移时，会遇到非常多的麻烦事。

4.  这意味着，业务需要尽量避免跨机房的分布式事务。如果一旦有参与分布式事务的服务节点所在的机房被DDoS打掉，那分布式事务带来的回滚和恢复，所给现存服务的影响不是一般的大……

5.  那尽量避免分布式事务，又能保证数据的快速一致性，还能再数据不一致的情况下快速恢复（毫秒级）到一个可接受状态，这对分布式架构的设计和业务的拆分能力，要求可不是一般的高。市面上常见的2-1/2-2，P7P8的“大神”给出来的方案基本上没有一个能过关的。

最后，讲讲我们当时被攻击的情况吧。

晚上9点多，刚下班，人刚到楼下大堂，车在外等着，一个电话打过来：我们被攻击了，你看一下。

马上手机热点电脑就地上网，看了一下，没影响。于是上车，车上全程电脑通过手机上网监控动态。直到第二天7点半，感觉持续一大晚上，也没给我们造成什么影响（除了流量），然后睡觉。下午3点多，回到公司，边监控，边复盘。

起因是，我们的客户受到了攻击，但客户所有的消息和信令，全走的我们的系统，所以攻击的流量，很大一部分就分到我们的系统上来。监控表明，攻击流量一直持续在240Gbps左右。

一开始，攻击方全面攻击我们的所有前端服务器。但我们是AWS的机房，带宽足够，而且我们的前端gate只是一个用户身份的代理，断线随便换，随时连接随时续上。所以，只要不停弹前端机就行，对客户毫无影响。客户接入用的是我们的SDK，我们在SDK内已经对意外断连和自动重连做过处理，所以，对客户的用户，毫无影响。

之后，攻击方发现全面攻击打不满我们的带宽，对用户的客户也毫无影响，于是攻击方改变策略，集中流量，一台一台地，打我们的前端机。打掉一台，打下一台。毕竟前端机也就千兆网卡，扛不住所有流量。

但话又说回来了，我们的前端机就只是一个用户身份的代理，弹新机器3分钟，重启2秒。等总网卡带宽能扛住攻击流量后，剩下的，就是不停重启。2秒后重启完毕，立刻投入服务，攻击者打了个寂寞…………

后面两天，我们该干啥干啥，也就时不时看一眼。

然后两天后，咦？咋不攻击了？